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PATENT APPLICATION 

DATA BROADCAST SYSTEM TO AID A BROADCASTER TO 
TRANSMIT AND RECEIVE DIGITAL INFORMATION OVER EXISTING 
5 AUDIO/VIDEO BROADBAND BROADCAST MEDIUM 

INVENTOR: CHRISTOPHER J. SCOTT DOUGALL 

m CROSS-REFERENCE TO RELATED APPLICATIONS 

Ifl 

-;P This patent application claims the benefit of U. S. Provisional Patent Application Serial 

H No. 60/129,754, entitled: DATA BROADCAST SYSTEM TO AID A BROADCASTER 

P 

SJ TO TRANSMIT AND RECEIVE DIGITAL INFORMATION OVER EXISTING 

lfL AUDIO/VIDEO BROADBAND BROADCAST MEDIUM, filed April 15, 1999, by the 

=P same applicant. 

y FIELD OF THE INVENTION 

P 

m The present invention relates to broadcast systems that include transmission of digital 

information with existing audio/video broadcasts. More particularly, the present 
20 invention relates to broadcast systems that include transmission of digital information 

with existing audio/ video broadcasts by utilizing software tools that source, schedule, 
and transmit and receive computer-type digital information over a broadband broadcast 
medium. 

BACKGROUND OF THE INVENTION 

25 The need to provide information to the public continues to challenge the information 

provider and has created numerous industries that includes radio, and television industry 
to present day Internet provider of on-line services utilizing telephone lines to carry the 
signals that contain the information. Accordingly, information is provided to the public 
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utilizing wireless communication technology, or by utilizing wired (cable) 
communications technology for providing the on-line services. The Internet, no doubt, 
via the World Wide Web (WWW), is a major source of information for the public. 
Although the personal computer has been an excellent tool to use as a means that 
facilitates getting information to individuals, the digital form of the information content 
used by the personal computer devices has been limited to utilization of on-line services 
via modem devices. 

The audio/ video industry, utilizing wireless broadcast technology, provides a 
excellent way of communicating information to the public. However, in present day 
working environments, traditional audio/ video equipment are not provided as part of the 
work-place tools. If the audio/ video equipment is provided, it is provided for 
entertainment purposes. The broadcast signals utilized by audio/video equipment do not 
include the digital signal information, such as the digital signal information transmitted 
by on-line services. Computer devices, on the other hand, have included audio/video 
peripheral equipment as part of the computer hardware multi-media componentry, and 
include digital signal receiving means for converting the on-line audio/video digital 
signal transmissions into audible and viewable information. 

The need for systems that combine the benefits of multimedia, wireless and wired 
on-line services has been recognized in U.S. Patent No. 6,021,433 to Payne et al. The 
Payne et al. patent teaches a data communication system that connects on-line networks 
with on-line and off-line computers and broadcasts the notification centric portions 
(headlines) of available network information. A computer user receives notification that 
there is an incoming message concerning the headlines. The Payne et al. patent further 
teaches that wirelessly broadcasted URLs, in the form of headline containing data 
packets, are provided for being used to obtain detailed data. While, the '433 patent has 
provided a data communication system for delivering network source headline messages 
utilizing wireless broadcasting, narrowcasting, and pointcasting, a need is seen for a data 
communication system and method that wirelessly broadcasts the full content of the 
network source information, not merely notification about the content that requires 
further action by the user to retrieve the details of the information. 

Accordingly, a primary object of the present invention is to provide a data 



communication system and method that wirelessly broadcasts the full content of digital 
network source information to a user. 

SUMMARY OF THE INVENTION 
The foregoing primary object of providing a data communication system and 
method that wirelessly broadcasts the full content of digital network source information 
to a user is accomplished by software tools that content source, schedule, and transmit 
and receive computer-type digital information over a broadband broadcast medium. The 
data communication system of the present invention, commercially known as Jetstream, 
and marketed by Sky stream Corporation of Thunder Bay, Ontario, Canada (formerly 
known as Varuna Software Inc. ) has a TCP/IP based communications layer that enables 
the suite of applications to be run across a local or wide area network. This layer also 
enables the system to be scaled to any size of operation, from one computer, to a large 
network of computers. The software tools comprise a server/head end, herein referred 
to as the Jetstream Server/Head End (Suite), a client/end user end, herein referred to as 
Jetstream Client/End, and a data stream format, herein referred to as Jetstream Stream 
Format. The Jetstream Server Suite is a group of integrated software applications, 
designed and tested to run on a personal computer operating system, such as the 
commercially available Microsoft Windows NT 4.0 operating system. This set of server 
end applications is used to facilitate the scheduled gathering and transmitting of the full 
content of digital information from a source, such as the WWW network source. The 
present invention comprises the following modules: 
Server/Head End 

• An application program, herein referred to as JetWeb, used for retrieving 
Internet information, and storing it locally. 

• An application module, herein referred to as JetQueue Module, used for 
transmitting scheduled services, that supports IP-Multicast, RS422, RS232, and 
TCP/IP communications, capable of broadcasting via conduits that comprise 
television, VBI, radio subcarrier, satellite (DSS,DVB), MPEG-2, paging 
networks, telephone networks, local area networks, the Internet. 

• An application module, herein referred to as Control Center, used to schedule 
tasks for the external modules, all other modules can be remotely controlled from 



the command center, allowing centralized organization of tasks and services. 

• An application program, herein referred to as JetMonitor, resident on all 
Jetstream systems, utilized to issue and respond remote commands and report on 
the status to remote modules. 

Client/End User End 

• An application program, herein referred to as Jetstream Client, for decoding and 
receiving the full content broadcast data that makes the full content information 
available to a computer desktop by storing files, caching web sites, and opening 
streams (sockets). 

• An application program, herein referred to as Jetstream Program Guide, used by 
the user to select which services to receive, or to view the schedule of incoming 
services, and to look at a catalog of what has been received, it also contains a 
rotating information (advertising) banner. 

The data communication system of the present invention, utilizes an industry standard 
ODBC database (supports MSAccess, Informix, SQLServer, Intrabase, ORACLE, etc.) 
for centralized scheduling and storage of data on a computer hard disk media. This 
allows the data to be integrated into the existing back office of the customer easily and 
efficiently. The data communication system of the present invention is designed to be 
independent of any broadcast hardware, and can be used to schedule the broadcast of 
many different services, such as standard files, web sites, program guide and rotating 
files, over many different media at the same time. The service files are sourced by a 
module source (Fetched) which in turn transmits the files to a broadcaster's hardware. 
The file contents are sent in pieces (or packets) by Jetqueue to a broadcaster hardware 
in a data stream, herein referred to as Jetstream Packet, which are formatted in a format, 
herein referred to as Jetstream Stream Format. The Jetstream Packet also comprises 
header information. By example, a web site service type is sourced by a sourced 
module, herein termed JetWeb Module, which establishes a connection to the specific 
web site, downloads the web sites files (similar to a Web Browser) , parses the received 
HTML, looking for any referenced element and fetches this as well. The website service 
files are packetized and then sent to the broadcaster's hardware as determined by 
JetQueue Module, for being received by a client. 




Other features of the present invention are disclosed or are apparent in the section 
entitled, "DETAILED DESCRIPTION OF THE INVENTION." 

BRIEF DESCRIPTION OF DRAWINGS 
For a better understanding of the present invention, reference is made to the 
5 accompanying drawings wherein: 

Figure 1.0 is a block diagram representation of the content-based data 
communication system of the present invention, illustrating a server/head end, a 
broadband broadcasting system and a client/end user end. 

Figure 2.0 is a flow diagram illustrating a content-based packet construction 
10 process in accordance with the present invention. 

Figure 3.0 is a diagram representation of a content-based packet, illustrating 
header byte and data byte allocations, in accordance with the present invention. 

Figure 4.0 is a block diagram illustrating a server/head end object hierarchy for 
'If server operation in accordance with the present invention. 

it\ Figure 5.0 is a block diagram representation of the server/head end JetQueue 

13 Control Center, illustrating interaction of selected system components, such as the 

SI ' Jetserver window, for monitoring and controlling transmission of scheduled content- 

based digital data communication services. 

■F 

M" Figure 6.0 is an exemplary JetQueue Control Center computer display window 

w 

2g| of Queue Properties illustrating general status information about transmission of 

^ scheduled services, in accordance with the present invention. 

Figure 7.0 is an exemplary client/end computer display window illustrating a 
program guide inventory of available services, herein referred to as Jetstream Program 
guide, in accordance with the present invention. 
25 Figure 8.0 is an exemplary client/end computer display window illustrating a 

program guide inventory and status of subscribed services, herein referred to as 
Jetstream Program guide, in accordance with the present invention. 

Figure 9.0 is an exemplary client/end computer display window illustrating on/off 
control of a broadcast receiver for receiving services, herein referred to as Jetstream 
30 Broadcast Receiver, in accordance with the present invention. 

Figure 10.0 is an exemplary client/end computer display window illustrating an 
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on-status of the on/off broadcast receiver services feature, including a pop-up window 
about viewing other options, herein referred to as Jetstream Broadcast Receiver, in 
accordance with the present invention. 

Figure 11.0 is an exemplary client/end computer display window illustrating an 
a view of statistics of broadcasted receiver services as selected from a pop-up window 
shown in Figure 10.0, herein referred to as Jetstream Statistics, in accordance with the 
present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1.0 shows an overview representation of the content-based data 
communication system (Jetstream) 100 in accordance with the present invention. As 
illustrated, content-based data communication system 100 comprises a server/head end 
110, a broadband broadcasting system 120 and a client/end user end 130/140. Jetstream 
100 is a data broadcast system and to that end server/head end 110 facilitates a 
broadcaster to add transmission of digital information to their existing audio/video 
broadcast. Server/head end 110, and a client/end user end 130/140 comprise software 
tools that source, schedule and receive the digital information transmitted by the 
broadcaster. 

The Jetstream 100 software tools are based on the concepts of services, modules 
and jobs. Services are defined as a logical grouping of computer files, modules are 
defined as a program that performs a specific task to the files of a service, and jobs 
control timing of when a module performs its assigned task. Services include by 
example, a standard file, which are an unrelated grouping of files, a web site service 
which are files that make up a WWW site, program guide services, which are files used 
to update the client program guide listing and rotational file services, which are 
unspecific related grouping of files. A broadcaster decides what services to create and 
transmit. Modules include fetch modules transmit modules, and combination fetch and 
transmit. Fetch modules, include webget, also referred to as Jetweb, and are utilized for 
updating the files within a service to add/delete/modify files, see generally Figure 1.0. 
Fetch modules also includes modules such as getmail, also shown in Figure 1.0. 
Transmit modules are modules such as JetQueue, that forward all files within a service 
to the broadcaster hardware designed to perform the actual signal broadcast to clients. 



JetQueue is the main transmit module, see generally Figure 5.0. Combination 
fetch/transmit modules include JetControl module and JetMonitor module. JetControl 
is a control center module that performs fetch operations on standard files and rotational 
file services. JetMonitor does not perform any task on a file service, but is used to start 
and stop modules in a distributed environment. Table 1.0 table breaks down by service 
type which module sources (fetches) the services files, and which module transmits them 
to the broadcaster specific hardware. 



Service type 


Service files are controlled by 


Service files are transmitted by 


standard file 


control center 


JetQueue 


web site 


JetWeb 


JetQueue 


program guide 


JetQueue 


JetQueue 


rotational file 


Control Center 


JetQueue 



Table 1.0 Service Type/ Module Relationship 



Jobs control when a module performs its assigned task to a service. Jobs are 
scheduled to run at a specific time and date. They are assigned to a service and a 
module . Jobs may be either a single job or a repeat job. A single job is scheduled to run 
once at a specific date/time. A repeat job is scheduled to run at a specific date/time, and 
to re-schedule itself to run again at a later date/time. By example, a repeat job may be 
schedule to repeat every two (2) hours. Table 2.0 breaks down by service type and 
module what happens upon running a service/module pair. 



Service tvne 


JetWeb Module 




Standard file 


n/a 


Send all files in the 
service to the 
broadcaster's hardware. 


Web site 


Establish a connection to the specific 
Web site, download the sites files 
(same as a Web Browser does) parse 
uic icccivcu. n i ivii^, luujvuig 101 d.ny 
referenced element, then fetch those 
elements as well. Repeat sa per 
setting of Web services. 


Send all files in the 
service to the 
broadcaster's hardware. 


Program Guide 


n/a 


Create a file that contains 
all information regarding 
available services, and 
send it to the 
broadcaster's hardware. 


Rotational Pile 


n/a 


Qol opt nnp ( c\t\\\j cxx\f*\ "ftl** 

LFllw ^Llliljr U11C ) 1 11C 

from the service and send 
it to the broadcaster's 
hardware. 



Table 2.0 Service type/Module Pair Run Results 



At the Client/end user end the software tools comprise two main applications with 
several support tools. The main client application tools are JetStream Broadcast 
Receiver, which listens for incoming streams of data sent by JetQueue, and JetStream 
Program Guide which provides a GUI to client operations, manages service 
subscriptions, displays broadcast schedules and displays active operations from the 
receiver. The broadcast Receiver runs continually in the background, displaying a small 
glyph in the icon tray. The Program Guide can be started and started at will and does not 
need to be operating for signal reception. 

JetStream 100 works by breaking the full content of the files into smaller pieces 
(packets) adding some header information to each packet and sending the file packets to 
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the client. The client/end user software reassembles the packets into the original files. 
The core of all JetStream broadcasts is the broadcasted JetStream Packets, which contain 
the full content of the digital data information from the services discussed above and 
which distinguish the present invention from other related teachings, such as U.S. Patent 
No. 6,021,433 to Payne et al. The following Table 3.0 describes a JetStream packet in 
accordance with the present invention. 



Stream Number 


Multiple Jobs can be active on JetQueue at one time, Stream 
Number determines for the client which job this packet is from. 


Packet Number 


Within a stream, each packet is numbered, so the client can 
determine if any packets have been lost during transmission, a 
common occurrence. 


Packet size 


the size of the data block 


Content 


(see Table 4.0) 


Data 


Data is interpreted based on content 


Sync Byte 


a special byte indicating the end of the packet 



Table 3.0 JetStream Packet 

The following Table 4.0 breaks down Content vs. Data within a JetStream 

Packet. 



Content Value is 


Then Data portion of Packet Contains 


JSJobBegin 


Details of a new job starting, its service code, job name, etc 


JSEntryBegin 


Details of a new file starting, file name, URL data, expected 
size 


JSEntryData 


actual file contents 


JSEntryEnd 


indicator that the current file entry has been completed 


JSJobEnd 


indicator that the current job has completed 



Table 4.0 Packet Content vs. data 



Table 5.0 shows as an example a job run for a standard file service. The standard 
file includes three files that are less than 1 Kbytes (filel.txt, file2.txt, and file3.txt). 
JetQueue begins a job run on the standard service and sends the packets to the client. 



Packet Sequence is: (a JetStream packet 
is created on this content) 


Signifies to the Client 


JS_JobBegin (with unique Stream 
Number) 


Transmission of the file service has 
begun on this Stream Number 


JSEntryBegin (beginning send of 
filel.ext ) 


Open for reception filel.ext 


JSEntryData (contents of filel.ext) 


save data block to filel.ext 


JSEntryEnd (end of send for filel.ext) 


close filel.ext 


JS_EntryBegin (beginning send of 
file2.ext.) 


Open for reception file2.ext 


JS EntryData (contents of file2.ext.) 


save data block to file2.ext 


JS_EntryEnd (end of send for file2.ext.) 


close file2.ext 


JS EntryBegin (beginning send of 
file3.ext.) 


Open for reception file3.ext 


JS_EntryData (contents of file3.ext.) 


save data block to file3.ext 


JS EntryEnd (end of send for file3.ext.) 


close file3.ext 


JS_JobEnd (completion of job on this 
Stream Number) 


all files received for this service 



Table 5.0 Example of sending a packet sequence 



Figure 2.0 shows a process 200 for breaking down files into packets generally 
shown as packet 300 in Figure 3.0. The packet construction process 200 begins a step 
201 where memory is allocated in a data storage, such as an ODBC data storage unit 
member of Server/Head end 110. The contents of the file are read (not created) at step 
202. The file data is then compressed at step 203 using a compression algorithm to 
reduce the packet size. The compressed data is then encrypted at step 204 using an 
encryption algorithm to scramble the packet. Framing is then performed on the 
encrypted packet at step 205. A trailer is added at step 206 to signal an end of packet 
(EOP). The desired wrapping is then added at steps 207a, 207b, and 207c, where step 
207a denotes a Wrap to NABTS (creates the forward error correction (FEC) bundles, fee 
rows and header), step 207b denotes Wrap to Null (no wrapper), and 207c denotes 
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Wrap to JPT (JetStream Packet Transport which are portions of a complete JetStream 
packet, and adds headers). The modified content file is then transmitted to broadcast 
hardware at step 208 and then the packet is destroyed at step 209 to restore/free-up 
memory in the storage unit member. Figure 3.0 shows packet 300 as being 127 bytes 
long, where bytes 0-4 are allocated for header H information and bytes 5-126 are 
allocated to data. Table 6.0 shows additional details of the packet format of the present 
invention. 



Byte# 


Description 


Details 


0,1,2 


Packet Address 


3 hamming perfect bytes. Indicates start of a JPT 
Packet and each byte must be from 0-15 (i.e. 242) 


3 


Continuity Index 


1 hamming perfect byte. Indicates portions of entire 
JetStream packet this portion os from. Starts at 0, 
ends when content flag indicates EOP. (wraps from 
15 to 0 as required) 


4 


Content Flag 


1 hamming perfect byte, bitmask indicating 
bit 0-full/filled packet* (padding added?) 
bit- 1 -last JetStream packet chunk 
bit 2,3-Future Fec/CRC details? 


5-126 


Data Chunk 


Clear portion of JetStream packet 



Table 6.0 JetStream Packet Format Details 



(*Note: Filler data is added as required to the end of the packet. First added character 
is OxEA then as many 0xl5's as needed to complete the 127 byte JTP packet size.) 

Figure 4.0 is a block diagram illustrating a server/head end object hierarchy for 
server operation in accordance with the present invention. This hierarchy assures 
encapsulation of all server operations into and out of the database. 

Figure 5 illustrates the JetQueue Module that is used for transmitting scheduled 
services, that supports IP-Multicast, RS422, RS232, and TCP/IP communications, that 
are capable of broadcasting via conduits, as illustrated in Figure 1.0, that comprise 
television, VBI, radio subcarrier, satellite (DSS,DVB), MPEG-2, paging networks, 
telephone networks, local area networks, the Internet to a Client/User end 130/140. The 
two components of JetQueue are the control Center Midi Window (JetServer Window) 
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and the broadcast service to drive the DLL (JetStream Broadcast Service) to a hardware 
transmission device. In one embodiment of the present invention Internet Protocol (IP) 
is used to move data to a wireless gateway, termed DBN. Figure 6.0 shows a computer 
display window showing the queue (JetQueue) general properties. From this window the 
server properties are configured. By example configure the route from the queue to an 
inserter device (serial Rs232, UDP/IP, TCP/IP, etc). The transmission rate in bits per 
second can also be specified from this window. The broadcast format can also be 
configured form this window. For example, for satellite (DVB) transmit JetStream with 
no wrapper. Packet compression can be enabled or disabled. 

The client receivers are populated via a Program Guide that contains information 
about the services available, and which allows a user to elect to receive or ignore the 
content. The content is saved as files in the storage unit of a user's computer, or is 
cached into a web browser for publishing the information in the users Program guide. 
Figure 7.0 shows an exemplary client/end computer display window illustrating a 
program guide inventory of available services. The program guide originates at the 
server /head end, at the control center and may include a default set of services which are 
made available to a user. Similarly, a user may select a file service, the file service is 
created and filled with the requested files and included as a job in the program guide. 
A web site service would have to be fetched and transmitted and handled in a similar 
fashion by the program guide. Figure 8.0 is an exemplary client/end computer display 
window illustrating a program guide inventory and status of subscribed services. Figure 
9.0 is an exemplary client/end computer display window illustrating on/off control of a 
broadcast receiver for receiving services. Figure 10.0 is an exemplary client/end 
computer display window illustrating an on-status of the on/off broadcast receiver 
services feature, including a pop-up window about viewing other options, such as 
statistics. Figure 11.0 is an exemplary client/end computer display window illustrating 
an a view of statistics of broadcasted receiver services as selected from a pop-up window 
shown in Figure 10.0. 

The present invention has been particularly shown and described with respect to 
a certain preferred embodiments and features thereof. However, it should be readily 
apparent to those of ordinary skill in the art that various changes and modifications in 
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form, material, and design detail may be made without departing from the spirit and 
scope of the inventions as set forth in the appended claims. 



13 



